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1.  INTRODUCTION 

An  important  component  of  the  Packet  Radio  project  is  the 
station  software,  providing  a variety  of  control,  coordination 
and  monitoring  functions.  BBN 1 s role  in  developing  this  software 
is  to  specify,  design,  implement  and  deliver  programs  which 
perform  these  functions. 

During  this  quarter  continued  progress  was  made  both  in 
design  areas  and  in  preparation  for  the  major  implementation  task 
of  modifying  the  Labeler  process  for  Channel  Access  Protocol 
(CAP)  version  5.  This  involves  negotiation  of  protocol  details 
with  co-contractors.  Section  2 below  covers  these  efforts. 

Section  3 of  this  report  covers  work  during  this  quarter  on 
station  software  itself,  followed  by  progress  in  internet  areas 
described  in  Section  4.  Of  particular  interest  here  is  the 
availability  of  the  new  TCP,  version  2.5.1,  as  well  as  further 
gateway  development  and  testing. 

Section  5 deals  with  hardware;  the  major  event  in  this  area 
during  this  quarter  has  been  the  installation  and  initial 
powering  up  of  two  radio  PR  units  at  BBN. 
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2.  MEETINGS,  TRIPS,  PUBLICATIONS 

2.1.  Meetings  and  Trips 

2.1.1.  PRWG  meeting 

BBN  personnel  attended  the  Packet  Radio  Working  Group 
meeting  this  quarter,  held  September  27-29,  at  Collins  Radio  in 
Texas.  Of  principal  concern  to  our  efforts  was  discussion  of  a 
down-line  load  service  for  Packet  Radio  units.  This  and 
subsequent  discussions  arrived  at  the  conclusion  that  the  station 
is  a logical  place  for  this  service,  and  initial  planning  of  its 
design  was  begun.  This  facility  will  receive  load  requests  from 
unloaded  PRs,  forwarded  to  the  station  by  the  network  of 
operating  PRs.  The  load  process  will  then  send  a sequence  of 
packets  to  each  PR  requesting  a load,  thus  enabling  the  PR  to 
begin  execution  of  Channel  Access  Protocol  and  enter  the  network 
as  an  operational  node. 

Also  at  the  PRWG  meeting  there  arose  further  support  for  the 
separation  of  the  station  tasks  and  the  internet  gateway  tasks. 
Discussion  of  our  efforts  in  minigateway  development  appears  in 
previous  reports  (especially  see  QPR  14,  pages  43-48) . 

Probably  the  most  immediately  vital  outcome  of  the  PRWG 
meeting  was  resolution  of  several  Local  ROP  (LROP)  design  issues. 
This  was  achieved  through  discussions  we  led  and  guided  by  our 
PRTN  259  (see  section  2.2).  It  was  decided  that: 

i 

- The  LROP  contains  station  ID,  labeled/unlabeled  flag,  load 
request  flag  and  sequence  number,  and  PR  type  (EPR/IPR) . 

- Periodic  LROPs  will  have  the  highest  priority  of  all  packets. 
This  is  to  assure  the  validity  of  link  quality  measurements. 

- PDPs  contain  the  link  quality  at  each  data  rate. 

- Dummy  traffic  exists  at  each  data  rate,  if  needed. 

- °DPs  are  not  always  sent  with  open/close  SPP  functions 
asserted . 
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- PDPs  contain  raw  transmit  counts  at  each  data  rate;  the  station 
may  in  the  future  use  this  to  avoid  congestion. 

And  finally,  UCLA  made  a request  at  the  meeting  for  a 
measurement  file  entry  to  announce  the  correspondence  between  a 
TIU  and  its  attached  PR's  IDs.  (See  section  3.1.2.) 

2.1.2.  SATNET  meeting 

We  hosted  a meeting  with  SATNET  representatives  November  6 
to  determine  the  configuration  of  gateways  and  port  expanders  at 
SATNET  sites.  The  main  issue  is  ARPA's  desire  to  have  an 
operational  SATNET  by  January  1,  in  preparation  for  use  of  SATNET 
connections  to  Europe  when  the  ARPANET  connection  to  London  is 
removed  in  June  of  1979.  The  current  plan  is  to  use  the  SIMPs  to 
provide  a virtual  "IMP-IMP  long  distance  telephone  line"  between 
the  United  States  and  England.  An  implication  of  this  is  that 
the  operational  gateways  will  not  be  available  for  debugging. 
Because  of  ARPA's  strong  concern  for  a continued  environment  for 
internet  development,  the  plan  arrived  at  has  two  gateways  at 
each  SATNET  site.  The  present  PDP-11/34  gateways  will  continue 
to  be  used  for  development,  while  new  LSI-11  minigateways  will  be 
installed  as  the  operational  gateways.  These  minigateways  will 
include  port  expanders  for  the  ARPANET  and  for  the  SATNET,  ports 
of  which  will  serve  the  PDP-ll/34s.  A copy  of  the  resulting 
configurations  and  a list  of  hardware  was  presented  to  ARPA.  The 
cost  of  the  new  hardware  required,  however,  is  a significant 
concern  and  throws  serious  doubt  on  this  approach  as  a means  for 
SATNET  operation.  The  cost  appears  to  exceed  $3f?0K. 

In  order  to  support  the  SATNET  port  expander,  modification 
of  the  Host/SIMP  protocol  is  planned.  Presently,  replies  from 
the  SIMP  carry  only  host  reference  numbers,  which  the  host 
matches  to  the  corresponding  request.  The  goal  is  to  support  two 
different  machines  attached  to  the  SATNET  port  expander,  each 
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running  a copy  of  Host/SIMP,  with  only  one  physical  connection  to 
the  SIMP.  The  main  change  is  that  every  message  will  carry  an 
address . 

2.1.3.  Internet  and  access  control  meetings 

At  the  Internet  meeting  held  at  SRI  in  October,  Virginia 
Strazisar  presented  our  ideas  on  congestion  control  in  the 
catenet.  We  are  in  the  process  of  implementing  an  alternate 
routing  scheme  in  the  gateways  as  outlined  in  IEN  #30.  In  this 
design,  gateways  exchange  information  with  each  other  regarding 
the  up/down  status  of  their  network  interfaces  and  their 
connectivity  to  gateways  on  the  same  networks.  This  information 
is  used  to  determine  shortest  length  routes  to  each  network  in 
the  catenet.  One  method  of  alleviating  congestion  which  was 
outlined  in  IEN  #30  is  to  load  split  traffic  on  all  routes  of 
equal  length.  We  are  currently  implementing  this  mechanism  as 
part  of  the  modifications  to  support  alternate  routing.  Although 
load  splitting  can  aid  in  controlling  congestion,  ultimately  the 
packet  sources  must  be  quenched  to  prevent  overloading  the  entire 
catenet.  Gateways  currently  drop  packets  which  they  cannot 
forward  due  to  congestion;  a simple  extension  of  this  mechanism 
is  to  notify  the  source,  identified  by  the  packet's  internet 
source  address,  that  its  packets  are  being  dropped.  The  internet 
source  can  then  quench  its  flow  of  traffic  into  the  catenet  in 
order  to  prevent  further  packet  loss.  Over  a period  of  time,  the 
source  can  again  increase  its  traffic  flow  into  the  catenet, 
backing  off  when  source  quench  messages  are  received  from  the 
gateway. 

Our  presentation  was  not  intended  as  a complete  design  for 
congestion  control  as  several  questions  remain  to  be  answered. 

In  particular,  if  several  sources  are  sending  traffic  into  one 
congested  gateway,  can  all  the  sources  be  treated  fairly?  and, 
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can  a gateway  detect  and  report  congestion  before  packets  are 
lost?  We  plan  to  continue  work  on  the  design  of  mechanisms  to 
control  congestion  and  propose  to  implement  these  as  an  addition 
to  the  gateway  alternate  routing  scheme  currently  being 
implemented . 

When  access  control  was  discussed  at  Internet  meetings,  it 
was  usually  treated  as  a local  problem,  in  which  gateways  would 
accept  or  reject  an  arriving  packet.  We  noted  that  it  is  a 
global  problem,  since  the  internet  has  to  route  a packet  over  a 
legal  route  if  one  exists.  Otherwise  a packet  would  be  dropped 
because  gateways  tried  to  send  it  via  a gateway  that  would  reject 
it.  People  proposed  fixes  to  this  problem  in  which  a packet, 

rather  than  being  dropped,  would  be  turned  back  on  its  path  until 

it  reached  a gateway  that  had  an  alternate  path  to  send  it  on. 

We  rejected  this  idea  as  impractical,  both  because  of  the  amount 
of  history  that  would  have  to  be  kept  either  in  the  packet  or  in 

gateways  to  remember  where  the  packet  has  been,  and  because  of 

the  inefficiency  of  groping  ones  way  through  the  internet.  We 
wrote  up  our  approach  to  solving  the  problem  of  access  control  in 
IEN  #58,  "Access  Control  — An  Informal  Discussion"  and  presented 
the  ideas  at  the  Internet  meeting  in  October.  At  the  meeting  it 
was  decided  that  discussion  of  the  topic  should  continue  and  a 
small  meeting  was  scheduled  for  November  at  ARPA.  At  the  ARPA 
meeting,  ARPA  explained  the  current  practical  reasons  for  the 
necessity  of  access  control,  and  introduced  a new  facet  of  the 
topic  that  needed  to  be  designed,  namely  spoof  protection.  We 
discussed  several  approaches  to  spoof  protection. 

2.1.4.  Meetings  with  Prof.  Gallager 

We  invited  Professor  Gallager  from  MIT  to  talk  to  us  about 
his  latest  work  in  routing,  especially  as  related  to  our  project. 
We  decided  that  it  would  be  beneficial  to  both  groups  to  keep  up 
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informal  contact  for  exchange  of  ideas.  Prof.  Gallager  invited 
us  to  occasionally  attend  the  informal  seminar  held  by  his  group 
at  MIT  each  week.  At  the  occasional  seminars  we  attended,  we 
listened  to  their  latest  research  directions,  filled  them  in 
about  our  current  state,  and  suggested  problems  that  they  could 
work  on  that  would  be  of  direct  benefit  to  us  such  as  congestion 
control,  alternate  routing  strategies,  intersubnet  route  setup  in 
a multistation  environment,  and  algorithms  for  dynamic  selection 
of  stations  in  a multistation  environment  in  which  PRs  and 
stations  could  change  identity.  We  expect  this  informal 
relationship  to  continue. 

2.1.5.  Meeting  with  McQuillan's  group 

During  this  quarter  we  participated  in  an  informative 
meeting  with  John  McQuillan's  ARPANET  group,  also  of  BBN.  John 
discussed  ARPANET  routing  and  recent  results  on  performance  and 
routing  design  (for  which  see  BBN  Report  No.  3803).  In  turn,  we 
explained  the  general  principles  of  the  PR  net  and  routing 
therein.  Although  the  routing  problems  each  group  must  solve  are 
vaguely  similar,  a major  difference  is  apparent  in  that  the 
shared  broadcast  channel  of  the  PR  net  approximately  constitutes 
a fully  connected  net,  only  some  arbitrary  portion  of  whose  links 
are  up  at  any  given  time.  The  ARPANET,  in  contrast,  is  sparsely 
connected,  by  links  which  are  usually  up.  An  aspect  of  ARPANET 
research  which  seems  more  applicable  to  PR  net  efforts  than 
routing  design  is,  is  study  of  traffic  level  variation  with  time. 
Essentially  all  measures  of  traffic  volume  in  the  ARPANET  were 
found  to  be  extremely  noisy.  This  places  grave  doubt  on  the 
applicability  of  routing  methods  such  as  that  of  MIT's  Prof. 
Gallager,  which  adjusts  to  the  marginal  delay  (derivative  of 
traffic  delay  with  respect  to  amount  of  traffic).  Unfortunately, 
we  have  no  reason  to  expect  traffic  level  (or  delay)  variation  in 
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2.1.6.  TCP  meeting 


BBN  personnel  participated  in  discussions  at  the  TCP 
meeting,  held  September  18-19  at  SRI.  Resolutions  from  that 
meeting  are  not  bearing  on  Packet  Radio  work  strongly  and  are 
reported  in  the  Internet  Experimenters  Notes,  and  so  will  be 
omitted  here. 

2.2.  Publications 

PRTN  258,  "Remaining  Issues  in  Stationless  Compatible 
Routing" 

This  PRTN  discusses  points  in  the  design  in  which  choices  of 
implementations  are  possible,  discusses  the  tradeoffs  between  the 
choices,  and  makes  recommendations  about  which  choice  should  be 
implemented . 

PRTN  259,  "Thoughts  Involving  LROP  Things" 

The  acronym  of  this  PRTN,  TILT,  brings  to  mind  the  cheat 
detection  of  pinball  machines  in  amusement  arcades.  The 
association  is  intentional.  In  digital  synthesis  of  music  and 
speech  sounds,  the  computer  community  grew  to  understand  and 
quantify  the  amount  of  precision  needed  to  reproduce  a sound  to  a 
given  degree  of  faithfulness.  Similarly,  the  author  sees  the 
networking  community  (and  the  PRWG  in  particular)  placing  faith 
in  a mechanism  (Local  Repeater  On  Packets,  to  measure  link 
quality)  before  fully  understanding  the  sampling  rate  needed  to 
secure  a meaningful  measurement.  This  PRTN  examines  some  of  the 
consequences  of  fluctuation  in  link  quality  measure  to  be 
expected  on  purely  statistical  grounds.  It  also  presents  some 
elementary  assessments  of  how  often  various  amounts  of 
fluctuation  should  occur.  Although  presented  at  the  PRWG  meeting 
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this  quarter,  this  PRTN  and  the  issues  it  raises  were  not 
discussed  in  depth. 

PRTN  260 r "Specification  of  a Rudimentary  Multistation 
Capability" 

This  PRTN  presents  a specification  of  a design  to  meet  the 
Packet  Radio  project's  need  of  robustness.  The  multistation 
capability  is  termed  "rudimentary"  because  it  makes  the 
simplifying  assumption  that  all  PRs  are  labeled  by  all  stations, 
and  thus,  although  it  meets  the  immediate  needs  for  the  PR  net, 
does  not  answer  the  future  need  of  network  expansion  that  a 
complete  multistation  capability  would  provide. 

PRTN  261,  "Resolution  of  LROP,  etc.  Issues" 

At  the  September  27-29  PRWG  meeting,  many  of  the  LROP, 
neighbor  table  and  PDP  design  issues  identified  in  PRTN  255  (see 
our  QPRs  14  and  15)  were  agreed  upon.  To  provide  a clear  and 
complete  documentation  of  these,  PRTN  261  was  written.  This 
document  serves  as  a specification  for  these  aspects  of  CAP  5, 
the  principal  changes  from  CAP  4.  One  item  of  remaining  concern 
is  whether  the  neighbor  table  will  be  able  to  store  all  the 
neighbors.  This  concern,  principally  voiced  by  BBN,  is  discussed 
in  PRTN  261,  and  implementation  alternatives  are  presented.  It 
will  be  interesting  and  informative  to  follow  the  performance  of 
the  neighbor  table  mechanism  in  the  months  to  come,  to  see 
whether  this  concern  is  justified. 

Internet  Experimenters  Note  58,  "Access  Control  — An 
Informal  Discussion" 

This  publication  was  distributed  to  the  internet  group  in 
conjunction  with  the  October  meeting.  See  section  2.1.3  for 
further  details. 
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2.3.  Negotiations  and  Informal  Documents 

2.3.1.  LROP,  etc.  design 

An  important  aspect  of  our  contribution  to  the  design  and 
specification  aspects  of  the  multi-contractor  Packet  Radio 
project  is  the  informal  negotiation  and  documentation  of  issues 
with  our  fellow  contractors.  This  quarter  saw  significant 
informal  contact  regarding  LROP,  neighbor  table,  and  PDP  design. 
The  PRWG  meeting  reported  in  section  2.1  was  followed  by 
additional  discussion,  principally  with  Collins  personnel 
implementing  these  features  of  CAP5  in  the  PRs.  Their  concern 
was  mainly  to  minimize  the  amount  of  code  required,  so  that  CAP5 
would  be  sure  to  fit  in  the  EPRs.  This  resulted  in  the 
publication  of  PRTN  261  (described  in  section  2.2). 

2.3.2.  1822  resolutions 

Also  this  quarter  we  distributed  to  Collins  Radio  and  SRI, 
at  their  request,  additional  copies  of  the  note  on  resolutions  of 
1822  interface  issues  reached  at  the  June  19-21  PRWG  meeting  (see 
QPR  15).  Additional  discussion  of  these  issues  arose  at  the 
September  27-29  meeting  this  quarter,  mainly  resulting  in 
agreements  that  Collins  would  revise  the  way  their  PR  software 
used  their  1822  hardware,  in  order  to  more  closely  conform  to  the 
prior  resolutions. 

2.3.3.  Route  suppression  bit 

Another  informal  negotiation  topic  this  quarter  has  been  the 
route  suppression  (RSUP)  bit  in  the  packet  header.  When  the 
station  forwards  a packet,  it  ordinarily  also  attempts  to  find 
and  assign  a point-to-point  route  for  further  such  traffic  to 
use.  If  the  RSUP  bit  is  set,  this  route  finding  and  assignment 
action  will  be  suppressed.  The  RSUP  bit  may  be  set  either  by  a 
PR,  or  by  an  attached  device  (e.g.,  TIU),  in  which  case  its 
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setting  is  preserved  by  the  PR.  The  concept  of  the  RSUP  bit  is 
presented  in  greater  detail  on  pages  9 and  11  of  our  QPR  15. 
During  this  quarter,  our  proposal  was  accepted  and  we  negotiated 
with  Collins  personnel  to  clarify  the  proper  implementation  of 
the  bit  in  the  PR. 

2.3.4.  Station  bibliography 

During  this  quarter  we  prepared  a brief  bibliography  of 
current  documentation  explaining  the  details  of  station  software, 
its  operation,  programming,  etc.  This  bibliography  is  as 
follows : 

Packet  Radio  Network  Station  notebook  — primary  reference; 
contains  various  PRTNs;  "Operating  the  Packet  Radio  Network 
Station"  is  a chapter  therein  and  constitutes  a user  guide  for 
the  station  operator. 

PRTN  174  revision  6,  "Packet  Radio  Network  Station  Labeling 

Process"  — describes  the  latest  version  of  the  labeler,  thus 
superseding  the  copy  of  PRTN  174  now  in  the  Station  notebook. 

PRTN  212  revision  5,  "Specification  of  Measurement  File  Entries" 

— describes  the  latest  format  and  contents  of  such  entries, 
thus  superseding  the  copy  of  PRTN  212  in  the  Station  notebook. 

PRTN  141,  "Cross-Network  Debugger  User's  Manual",  and 
BBN  Report  3377,  "XNET,  Cross-Network  Debugger  for  TENEX,  User's 
Manual"  (which  is  an  update  of  PRTN  141),  and 
[BBNA] <ELF>XNETUPDATE. DOC  on-line  computer  file 

— these  describe  the  use  of  XNET  to  load,  debug,  monitor, 
remotely  control,  and  interact  with  the  station.  Use  of  the 
disk  for  storing  software  is  also  covered.  This  manual  is 
ordinarily  distributed  with  the  Station  notebook. 

PRTN  125,  "Functions  and  Structure  of  a Packet  Radio  Station"  — 
PRTN  version  of  1975  NCC  paper.  Describes  initial  design  of 
station.  Good  background  material. 
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PRTN  216,  "Specification  for  an  ELF  System  with  Disk  and  Net 
Loading  Facilities"  — covers  major  extensions  made  to  ELF 
specifically  to  support  PRN  needs.  Reference  for  ELF 
operating  system  itself  is  "ELF  System  Programmer's  Guide", 
available  on-line  but  written  at  SCRL,  not  BBN. 

Also,  certain  BBN  PRTNs  bearing  on  SPP  and  CAP  are  relevant, 
although  these  are  not  peculiar  to  the  station.  These  are: 
PRTN  177,  "SPP  Definition", 

PRTN  194,  "Point-to-Point  Routing  Proposal",  and 
PRTN  239,  "Use  of  IDs  in  Routes". 
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3.  THE  PACKET  RADIO  NETWORK 

3.1.  Station  Programing  and  Testing 

3.1.1.  ELF  system 

We  released  a new  ELF  and  connection  process  to  support  more 
connections  for  measurement  runs.  In  particular,  there  is  no 
XRAY  process  in  this  configuration;  the  connection  process  uses 
that  space  for  increased  storage. 

The  gateway  has  been  modified  to  interpret  both  version  2.5 
and  version  4 internet  headers.  In  interpreting  version  4 
internet  headers,  the  gateway  checks  the  packet  length  field, 
checks  and  decrements  the  time  to  live  field,  and  verifies  the 
internet  header  ones-complement  checksum.  The  gateway  does  not 
yet  support  fragmentation. 

3.1.2.  Labeler 

Several  small  improvements  to  the  CAP4.9  Labeler  were  made 
during  this  quarter. 

1)  The  Labeler  dialogue  was  enhanced  to  include  a no  change 
option  for  the  yes/no  questions  pertaining  to  the  running  of 
the  Labeling  process. 

2)  Some  source  files  for  the  Labeler,  which  had  been  destroyed 
during  a period  of  severe  disk  problems  in  late  August,  were 
recreated  through  older  sources  and  editing  notes. 

3)  A new  Labeler  was  delivered  to  SRI  incorporating  the  TIU  ID  - 
PR  ID  measurement  entry  requested  by  SRI  and  the 
carriage-return  default  for  parameter  setting  in  the  Labeler. 
Also  included  in  the  delivery  were:  PRTN  212  revision  6 
describing  the  new  measurement  entry,  an  updated  labeler 
chapter  of  the  station  operator's  guide,  and  an  updated 
version  of  PRDATA  which  handles  the  new  measurement  entry. 
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The  major  effort  was  directed  toward  the  CAP5  labeler,  in 
both  design  and  code  generation.  Portions  of  the  Labeler 
pertaining  to  the  assignment  and  use  of  good  neighbors  were 
removed,  and  the  resulting  Labeler  tested. 

The  connection  handling  was  redesigned  to  handle  both  SPP 
and  non-SPP  connections  with  the  same  routines.  This  proved 
useful  in  the  subsequent  implementation  of  the  listening 
connection;  this  third  type  is  an  SPP  connection  initiated  by  the 
Packet  Radio  Units  to  send  PDPs . The  design  was  implemented  and 
then  tested  through  mock  SPP  packets  generated  by  XRAY. 

3.2.  Support 

SRI  asked  about  the  XNET  debugger  sending  (internet)  packets 
which  are  too  large  for  a PR  net  to  transport  in  its  packets.  In 
response,  we  prepared  a version  of  XNET  which  knows  about  the 
packet  size  limitation  of  PR  nets  and  reduces  its  packets 
accordingly.  Such  an  XNET  debugger  may  be  used  by  SRI  to  debug 
TIUs,  for  example. 
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4.  INTERNETWORKING 

4.1.  Transmission  Control  Program  (TCP) 

Code  aimed  at  repairing  all  reported  TCP  bugs  has  been 
included  in  the  TCP  sources  for  TENEX  and  TOPS 20.  After  some 
period  of  negotiation,  a 2020  became  available  for  monitor 
debugging  at  Digital  Equipment  Corporation  in  Marlboro, 
Massachusetts.  This  machine  is  now  being  used  two  afternoons 
each  week  for  TCP  activities. 

On  21  November  1978  TC?  version  2.5.1  was  installed  for 
experimental  testing  by  members  of  the  Packet  Radio  group. 
Somewhat  after  this  the  group  at  UCL  produced  a program  which 
could  cause  a monitor  crash.  Upon  investigation  the  cause  was 
traced  to  a questionable  definition  of  a "standard"  macro  which 
is  intended  to  decrement  a structure  field.  The  standard 
definition  did  not  consider  the  carries  produced  by  decrementing 
a 0 and  thus  modified  the  field  to  the  left.  The  reason  this 
showed  up  only  in  the  UCL  program  is  that  it  is  the  first  program 
which  had  TCP  buffers  in  page  0 of  its  address  space.  It  was  the 
"current  buffer  page"  field  which  was  being  initialized  using  the 
DECR  macro.  The  problem  was  repaired. 

The  first  version  4 TCP  was  produced  by  editing  the  current 
version  2.5.2  files,  changing  structure  definitions  and 
algorithms  as  needed.  Thus  4.0.0  performance  and  capabilities 
are  identical  to  version  2.5.2. 

4.2.  Gateways 

In  order  to  verify  the  performance  of  version  4 (Internet 
Protocol)  gateways,  a program  call  GWTEST  (Gateway  test)  was 
constructed.  Basically  it  started  as  a previous  incarnation 
(SIQTST)  and  was  modified  to  handle  version  4 of  IP. 
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Testing  of  version  4 hosts  may  be  done  using  a testing 
gateway  program.  This  program  functions  as  a gateway  from  the 
ARPANET  to  the  ARPANET  and  may  be  run  on  any  TENEX  or  TOPS20 
machine.  This  gateway  is  purposely  designed  to  accentuate  real 
world  shortcomings  which  will  be  encountered.  For  instance,  the 
testing  gateway  introduces  errors,  some  of  which  are 
undetectable,  delays,  drops  and  reorders  packets.  In  certain 
special  cases  such  as  TCP  packets  which  have  the  SYN  control  bit 
set,  the  probabilities  are  different  so  as  to  provide  more  of  a 
“worst  case”  communications  medium  simulation. 

During  this  quarter  we  were  asked  for  clarification  of  the 
solution  to  the  i/o  blocking  problem  between  the  Host/SIMP 
protocol  module  and  the  Reliable  Transmission  Protocol  (RTP)  code 
in  gateways  on  the  SATNET.  (See  QPR  14,  top  of  page  43  for 
further  background.)  The  motivation  for  the  solution  we  chose  is 
as  follows.  Both  the  RTP  code  and  Host/SIMP  each  have  a limited 
number  of  buffers  for  communicating  with  each  other.  All  of 
RTP's  buffers  may  happen  to  be  waiting  for  write  operations  to 
Host/SIMP  to  complete.  We  cannot  allow  all  of  Host/SIMP' s 
buffers  to  be  writing  to  RTP,  since  that  can  lead  to  the  deadlock 

described  in  QPR  14.  Thus  at  least  one  Host/SIMP  buffer  should 

be  used  to  read  from  RTP.  If  that  buffer  is  then  filled  with  a 

packet  which  turns  out  to  be  unacceptable  at  this  moment  (such  as 

if  it  were  destined  for  writing  to  RTP,  thus  threatening  a 
deadlock),  the  packet  must  be  discarded  ("refused").  To  refuse 
the  packet  Host/SIMP  must  (per  protocol  specification)  send  the 
SIMP,  via  RTP,  a message  saying  that  this  packet,  identified  by 
"host  reference  number",  was  refused.  To  send  this  refusal 
message  it  must  exist  in  a packet  buffer,  but  there  are  no  packet 
buffers  available.  (The  buffer  freed  by  dropping  the  refused 
packet  just  received  from  RTP  must  be  re-used  to  maintain  a read 
outstanding  from  RTP.)  Thus  we  are  in  a very  difficult 
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situation.  To  avoid  deadlock  we  must  keep  a read  outstanding, 
and  to  do  this  we  must  be  capable  of  (occasionally,  we  hope) 
dropping  packets,  and  to  do  that  we  must  send  packets  for  which 
we  have  no  buffers.  Our  solution  is  to  say  that  this  condition 
is  one  we  expect  to  be  transitory,  and  that  a short  list  can  be 
kept  of  host  reference  numbers  for  which  Host/SIMP  should  send 
refusal  notifications  when  the  condition  eases.  If  this 
condition  is  not  transient,  that  is,  if  it  persists  so  long  that 
the  several  slots  on  the  list  are  insufficient,  then  this  is 
presumably  symptomatic  of  a major  foul-up  in  communications,  and 
issuing  a "restart  request"  to  clear  the  situation  is 
appropr iate . 

Debugging  of  the  Host/SIMP  protocol  module  of  the  gateway  in 
conjuction  with  actual  SIMPs  was  begun.  Joint  debugging 
uncovered  bugs  in  the  Host/SIMP  module  of  the  gateway  that  did 
not  arise  in  loop-back  mode.  The  main  bug  was  associated  with 
packets  being  byte-swapped  (since  in  loop-back  mode,  the  packets 
would  be  doubly  byte-swapped  and  therefore  seen  as  correct) . 

Also,  a modification  was  made  to  the  restart  logic  in  the 
protocol,  and  we  were  initially  not  compatible  with  the  SIMP, 
which  was  implemented  after  the  protocol  change  was  made.  Other 
bugs  occurred  because  the  core  gateway  had  undergone 
modifications  in  the  months  between  loop-back  debugging  of  the 
Host/SIMP  module  and  joint  debugging  with  the  SIMP,  so  that  the 
Host/SIMP  module  was  no  longer  compatible  with  the  core  gateway. 
These  bugs  were  all  dealt  with,  but  it  was  decided  that  release 
of  all  the  software  would  wait  until  streams  were  implemented  in 
the  SIMPs  and  could  be  tested  with  the  gateway. 


16 


BBN  Report  No.  4124 


Bolt  Beranek  and  Newman  Inc 


5.  HARDWARE 

5.1.  Boston  Area  PR  Network 

At  the  close  of  the  last  quarter,  we  were  almost  ready  to 
install  the  two  PRs  at  BBN.  These  will  be  useful  for  three 
reasons : 

1)  The  new  PRs  will  be  identical  to  those  in  operation  at  SRI  and 
Collins.  They  will  not  require  software  patches  to  use  a 
second  1822  interface,  normally  connected  to  the  radio  unit, 
to  simulate  radio  connectivity,  as  the  PRDUs  (Packet  Radio 
Digital  Units)  we  have  been  using  do.  Also,  the  PRs  will  be 
capable  of  executing  the  CAP  5 code,  which  will  depend  on  a 
new  PROM  operating  system  not  present  in  the  PRDUs. 

2)  The  radio  link  will  permit  more  realistic  testing  and 
debugging,  since  it  may  occasionally  drop  (and  hence  cause 
duplication  of)  packets.  The  PRDU  digital  link  is  error-free, 
so  problems  arising  from  imperfect  link  performance  could  not 
be  addressed  in  the  BBN  test  bed. 

3)  The  two  PRs  will  constitute  the  beginnings  of  a Boston  area  PR 
network.  As  PRs  are  added  in  the  future,  users  at  MIT  and 
Lincoln  Labs  will  have  the  opportunity  to  experiment  and 
utilize  the  net.  Also,  our  station  testing  and  debugging 
activities  will  become  increasingly  realistic  as  the  size  of 
the  Boston  net  increases.  Problems  of  scale  will  appear  here, 
where  they  are  more  quickly  identified  and  remedied,  instead 
of  at  SRI. 

The  one  remaining  piece  of  hardware  necessary  for 
installation  of  the  PRs  was  1822  interface  cable.  This  arrived 
early  this  quarter  and  was  installed,  connecting  the  PR  on  the 
seventh  floor  to  a PDP-11  in  the  North  Bay  computer  room  on  the 
first  floor. 
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We  requested  and  received  final  permission  from  ARPA  to 
generate  RF  radiation  in  the  Boston  area  by  operating  the  PRs . 

We  then  invited  Collins  personnel  to  visit  our  facilities  for  a 
final  check  prior  to  powering  up  the  PRs.  This  visit  occurred 
November  16-17. 

Unfortunately,  a lack  of  familiarity  with  PRs  on  the  part  of 
our  technicians  assembling  them,  together  with  a lack  of 
documentation  regarding  a particular  detail,  resulted  in  improper 
assembly.  The  connector  for  the  maintenance  monitor,  which  is 
not  clearly  labeled  and  is  not  keyed,  was  installed  upside  down 
in  both  PRs.  This,  we  hypothesize,  caused  one  or  more  power 
supply  voltages  to  take  back  paths  through  the  maintenance 
monitor  circuits  and  return  to  the  main  PR  circuits,  where  they 
were  applied  to  sensitive  RF  components.  The  result  was  a 
burn-out  of  parts  of  each  PR,  causing  total  inoperability. 

We  shipped  both  PRs  back  to  Collins  for  repair.  Since  then, 
measures  have  been  taken  to  make  the  proper  installation  of  the 
maintenance  monitor  connector  clearer.  Unfortunately,  this 
setback  may  adversely  affect  our  delivery  of  station  software 
compatible  with  CAP  4.8,  since  we  have  no  on-site  debugging 
facilities.  (The  PRDUs  cannot  run  CAP  4.8  due  to  PROM  operating 
system  changes.)  We  plan  to  use  SRI  facilities  remotely  as  much 
as  possible  to  minimize  this  impact. 

5.2.  Miscellaneous  Hardware  Work 


The  only  additional  hardware  efforts  this  quarter  were 
treatment  of  a failed  microcode  ROM  in  station  PDP-11  number  2, 
and  some  intermittent  problems  with  station  PDP-11  number  1.  A 
service  call  from  DEC  cured  the  former,  while  some  work  by  our 
technicians  fixed  the  latter. 
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